home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000808_dsr@hplb.hpl.hp.com _Fri Apr 2 18:46:58 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB

  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA19990; Fri, 2 Apr 93 18:46:58 MET DST
  4. Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA18951; Fri, 2 Apr 1993 19:05:49 +0200
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 2 Apr 93 18:00:10 +0100
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA20689; Fri, 2 Apr 93 18:06:54 +0100
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9304021706.AA20689@manuel.hpl.hp.com>
  11. Subject: WWW access and ensuring confidentiality
  12. To: www-talk@nxoc01.cern.ch
  13. Date: Fri, 2 Apr 93 18:06:51 BST
  14. Cc: sfk@hplb.hpl.hp.com
  15. Mailer: Elm [revision: 66.36.1.1]
  16.  
  17. Here at Hewlett Packard, we need a way of preventing unauthorised
  18. access to information, but want to take advantage of the WWW for
  19. sharing information with colleagues.
  20.  
  21. Please give me your comments on our proposed solution.
  22.  
  23. I am working on a solution that makes use of UNIX's established
  24. security mechanisms and making it easy for non-technical types
  25. to manage things for themselves without the need to call out
  26. the support staff.
  27.  
  28. Each web server can be run in two modes depending on a command line switch:
  29.  
  30.   Mode 1
  31.   ======
  32.  
  33.     a)  all world readable files are accessible
  34.     b)  systems in the .rhosts file are treated appropriately
  35.     c)  all other files require a user name & password
  36.  
  37.   Mode 2
  38.   ======
  39.  
  40.     a)  systems in the .rhosts file are treated appropriately
  41.     b)  otherwise all files 
  42.  
  43. The Authorisation: field in HTTP2 is used to carry the username
  44. and password, e.g.
  45.  
  46.     Authorisation: user fred:secret
  47.  
  48. Where "user" identifies the following as being username:password
  49. which must refer to a valid user account on the host system. This
  50. approach avoids the need for people to manage special configuration files.
  51. We may also add a file similar to the .rhost file but specific to the web.
  52.  
  53. The browser keeps track of which system/protocol needs what user name/
  54. password, and so only asks you once for each system per session. I am
  55. also looking at using X11's interprocess communication facilities so
  56. that multiple concurrent invokations of the browser can share the
  57. same info to further minimise the pain.
  58.  
  59. The same approach is also used for our gateway from our closed subnet
  60. to the rest of the world. This gateway relays tcp connections, but doesn't
  61. accept requests to connect from the outside. I hence have to use ftp in
  62. the passive mode.
  63.  
  64. In the future we will investigate more flexible approaches such as Kerberos
  65. that avoid sending passwords in clear (unlike most UNIX apps such as ftp,
  66. rlogin etc.).
  67.  
  68. Dave Raggett
  69.  
  70. Hewlett Packard Labs, Bristol, UK
  71.  
  72.     +44 272 228046
  73.     dsr@hplb.hpl.hp.com